Method for organizing and executing a plurality of services in particular on board a motor vehicle

ABSTRACT

A method for organizing and executing a plurality of services, in particular on a motor vehicle. According to the method, a) a plurality of cases of use are defined for each of which, within a context, a demand invokes a reaction that implements a particular functionality, and b) the reaction is selectively activated upon detection of the transmission of the demand within the context.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to a method for organizing and executing aplurality of functionalities, especially in a motor vehicle.

2. Discussion of the Background

From International Patent WO 99/56201 there is known a method forreprogramming a system forming part of a motor vehicle (internalcombustion engine, electric motor, brake system, etc.) or of a systemrelated to a user of the said vehicle (mobile telephone, navigationsystem, radio receiver, etc.). Such reprogramming may be necessary toensure execution of a functionality such as, for example, the adjustmentof the operation of the engine after a certain operating time, or theupdating of the list of telephone numbers recorded in the directory ofthe mobile telephone. The described method, designed to ensure areprogramming accessible only to authorized persons or entities,executes such reprogramming or programming of a new function by means ofremote input, into a microprocessor, of a compiled executable code of acomplete software program capable of assuring this reprogramming or ofexecuting this new function. The input of such a complete softwareprogram obviously takes place at high data rate. Thus it isdisadvantageously cumbersome to use.

SUMMARY OF THE INVENTION

The object of the present invention is to provide an automaticcontroller on the basis of a plurality of cases of use that define afunctionality.

Another object of the invention is to permit reprogramming offunctionalities, specific to a motor vehicle, for example, by modifyingalready installed functionalities or adding new functionalities, suchreprogramming not requiring knowledge of the architecture of themicroprocessor used for execution of the functionalities. Thereby itinvolves a much smaller volume and is executed by means of informationtransfer at low rate, by comparison with that required by the methoddescribed in the cited patent.

This object of the invention as well as others that will become apparentupon reading the description to follow is achieved with a method fororganizing and executing a plurality of functionalities, especially in amotor vehicle, this method being noteworthy in that a) there is defineda plurality of cases of use (CU) for each of which, within a context(C_(i)), a demand (D_(j)) invokes a reaction (R_(k)) that implements aparticular functionality, and b) the said reaction is selectivelyactivated upon detection of transmission of the said demand (D_(j))within the said context (C_(i)).

As will be seen in detail hereinafter, this method makes it possible, inreturn for a prior refined analysis of the architecture, to include thefunctionalities in question in the executable software, to subsequentlymodify these functionalities or to add new functionalities, by means ofinputting information at much lower rate than in the case of the methoddescribed in the cited International Patent WO 99/56201, the use of suchinputting then being much easier.

BRIEF DESCRIPTION OF THE DRAWINGS

Other characteristics and advantages of the present invention willbecome apparent upon reading the description hereinafter and examiningthe attached drawing, wherein:

FIG. 1 is a graphical representation of an automatic controllercorresponding to the use of the present invention,

FIG. 2 is a graphical representation of an another automatic controllercorresponding to the use of the present invention for a particularfunctionality within different contexts, and

FIG. 3 is a functional diagram of an automatic controller of the type ofthat illustrated in FIG. 2, adapted, for example, to control of the airconditioning of the passenger compartment of a motor vehicle, accordingto the inventive method.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

A motor vehicle is normally provided with a plurality of physicalsystems: motive power unit and devices for braking, suspension, heating,air conditioning, communication, etc., for use by the vehicle driver inorder to achieve diverse “functionalities”.

The first step of the method according to the invention comprisesformalizing the cases in which the driver uses each of the systems. Forthis purpose, an operating “context”, the driver's “demand” and the“reaction” of the system to such a demand transmitted within the saidcontext is defined for each of these “cases of use”.

As an illustrative and non-limitative example:

1) the context of use may be composed of information obtained from theenvironment: temperature of the passenger compartment, speed of thevehicle, driving condition (outside temperature, presence of rain,etc.). Such information can be detected by means of appropriate sensorsor else can be calculated.

The context may also take into account information produced duringprevious reactions during use of the functionality.

2) the driver's demands are his actions on elements or interfaces(pushbutton, key, vocal-command recognition device, etc.) that enablehim to request or modify one of the functionalities offered by thevehicle. The demands may be implicit when the driver is not in controlof the situation; for example, putting himself in an accident situationis a demand for which the driver is not responsible.

3) the reactions of the system are events that activate thefunctionalities themselves: turning on the windshield wipers, activationof a flashing light, display of an icon on a screen, etc.

The formalization of the cases of use is supplemented according to theinvention by timing information that indicates the delay with which areaction must be used and the delay with which a context or a demandmust be taken into account.

As an example of cases of use defined in this way there can be cited thefollowing: regardless of the value of the vehicle parameters, a driver's“demand” represented by pressing the “emergency lights” pushbutton—whichis a demand that must be taken into account—invokes a “reaction” whereinfour flashing lights having a repeat frequency of 2 Hz are turned on.

In this way there are established three formalized lists of contexts,demands and reactions.

The identified cases of use (CU) can be combined as functionalities thatare independent of one another (such as, for example, wiping of windowsand the operation of an illuminating device), activated concurrently ifnecessary. Hereinafter there will be described only the inventiveorganization of a single functionality, the other functionalities beingorganized analogously.

To define the automatic controller corresponding to all functionalities,the following steps are performed. During a first step, a firstfunctionality is taken into account. During a second step, for thefunctionality under consideration, the contexts CA_(i) of the automaticcontroller that each represent a set of values of the vehicle parametersthat are not affected by the functionality but that affect thefunctionality are identified. For example, whether the engine isstationary or running is not affected by the air-conditioningfunctionality, but it affects that functionality.

In a third step, for each context CA_(i) of the automatic controller andfor each case of use CU_(j) whose context corresponds to CA_(i), thereis defined for each response R_(ij) of the case of use CU_(j) a stateE_(ij) such that, by definition, R_(ij) is executed when E_(ij) isaccessed.

In a fourth step, there is initiated an iterative process that stopswhen an iteration does not add a further transition to the automaticcontroller.

During each iteration of this iterative process, the following steps areperformed for each case of use CU_(j):

-   -   identification of pairs (CA_(i), E_(jk)) compatible with the        context of the case of use CU_(j),    -   creation, in the automatic controller, for each of these pairs        (CA_(i), E_(jk)), the transition that leads from (CA_(i),        E_(jk)) to (CA_(j), E_(lj)) by the demand D₁ of the case of use        CU_(j), where E_(lj) is a state implementing the response of the        case of use CU_(j), and

if the state E_(lj) does not already exist, addition within the contextCa_(j) of the automatic controller.

Return to the stop condition at the beginning of the iteration.

Finally, there is a return to the second step, for another functionalitythat has not yet been processed.

If a case of use is added to a functionality during a new step, thethird and following steps are reproduced if the new case of use inducesa new response. Otherwise a skip to the fourth step takes place.

It is noted that the context represents at least one mode of operationof the system, the modes being available in all functionalities andbeing beyond the direct control of the functionalities, for example amode representing an available energy level and/or a type of user of thesystem and/or an accident or non-accident condition of a vehicle.

In particular, the context may represent a context of the automaticcontroller of the system, composed of a complete combination of modes ofoperation of the vehicle, the contexts of the automatic controller inthis way being available to all functionalities, the cases of userepresenting all the responses or absences of response of the systemwithin all contexts of the automatic controller, those representingtogether all combinations of the modes of operation of the vehicle.

When, within a context Ca of the automatic controller, the differentstates correspond to different reactions Rj, then they are characterizedby the pairs (Ca, Rj) and it is not necessary to name them (conventionused for FIGS. 1 and 2).

Before concluding the study making it possible to establish the contextsof use CU, it is appropriate to make sure that this study is exhaustive.

For this purpose there will be defined, for each functionality, theformalized demands that may occur “simultaneously” by virtue of thedelay with which they are taken into account or because several usersmay have access to them. The CUs obtained for each context with a set ofconcurrent demands that form a new formalized demand to be designated as“simultaneous demand” will then be validated or invalidated, as will aformalized reaction in the list of formalized reactions of thefunctionality.

Preferably a change of context of the automatic controller will havehigher priority than a formalized demand. Thus the possibility ofsimultaneous occurrence does not have to be taken into account in thiscase. If a demand to change the context of the automatic controller anda simple driver's demand occur concurrently, the change of context ofthe automatic controller is processed first, then the formalized demand.By definition, two changes of context of the automatic controller cannotarrive simultaneously (for example, the aforesaid contexts of “enginerunning” and “engine stationary” obviously cannot coexist).

It is also appropriate to ensure that the formulated automaticcontroller is correct. During this step, if two states of the automaticcontroller are linked by different demands in the same initial state,the need to define a priority between the system responses is thendetermined, and this priority is incorporated as an attribute of theoutputs of the state. Typically, priority information comes after thecases of use have been designed. It is possible that, for mechanical orother reasons, two potentially concurrent demands can in fact never beimplemented concurrently. In this case, it is necessary to wait for amore advanced design step to be certain that it is not necessary tospecify a priority, unless that can be guaranteed directly (example:opening a door and closing a door). In addition, if two identicaldemands lead to different states, there then exists an incompatibilitythat must be corrected, and one of the demands must be suppressed andtherefore the corresponding case of use must be defined.

It is also appropriate to ensure that the formulated automaticcontroller is complete according to the process explained hereinafterwith reference to FIG. 1, which is a graphical representation of thisautomatic controller for the case in which the preliminary study hasmade it possible to identify a single context C₀ of the automaticcontroller, two demands D₁ and D₂ and 5 possible reactions (R₁ to R₅).In FIG. 1, the different states (C_(i), R_(k)) are represented bycircles and the transitions between states upon demand D₁ or D₂ arerepresented by solid arrows. Thus, for example, the transition fromstate (C₀, R₂) to state (C₀, R₄) takes place by demand D₁, and from thislatter state to state (C₀, R₅) by demand D₂.

Dashed arrows schematically illustrate potentially missingtransitions—not represented by a solid arrow—upon demand D₁ or D₂. It isseen that if the transitions from the state (C₀, R₂) upon demand D₁ orD₂ are complete, the same is not true for the other 4 statesrepresented.

For each of these other states (C_(i), R_(k)), it will then be necessaryto verify that the demand D₁ or the demand D₂ cannot trigger atransition to another state.

At the hardware level, the different identified contexts, demands andreactions can be recorded at various predetermined locations in RAM inthe form of a Boolean value set to “1”, for example to signal theexistence of this or that context of the automatic controller or demand,or to produce this or that reaction. An appropriate computer, such as aduly programmed microprocessor, or hardware means such as a wired orprinted circuit, make it possible to give physical form to the automaticcontroller used in the present invention.

Referring now to FIG. 2 of the attached drawing, the structure of anautomatic controller suitable for using a particular functionalitywithin different contexts C₁, C₂ and C₃ of the automatic controller isgraphically illustrated. Demands D₁, D₂ make it possible to command,depending on the context of the automatic controller, transitions to thestates characterized by the reactions R₁, R₂ or R₃. As an example, blockR₃ details the reactions activated in state (C₁, R₃): sensing of values,magnitudes, execution of different functions, diverse commands, etc. Ineach of the three blocks marked c1, c2, c3 there are grouped the statesidentified within the contexts C₁, C₂ and C₃ respectively of theautomatic controller.

As for the automatic controller of FIG. 1, the solid arrows illustratethe transitions between states commanded by demands D₁ or D₂ formulatedby the vehicle driver. In contrast, the unidirectional or bi-directionaldashed arrows illustrate transitions between contexts of the automaticcontroller.

Thus, a demand D₂ formulated from a state (C₁, R₃) commands a transitionto state (C₁, R₂). If a demand D₃ implying a change of context of theautomatic controller then appears, the state evolves to the state (C₂,R₂) shown in block c2.

The automatic controller permitting execution of the particularfunctionality in question having been defined (as illustrated by FIG.2), what remains is to encode and input the said automatic controllerinto RAM, as indicated hereinabove. A demand monitor observes at eachinstant the state of the Boolean values representing these demands. Thetransitions between states resulting from these demands and conditionsdictate the activation of sensors, elements, functions or commands withwhich the demanded functionality can be executed in any of the statesidentified during the analysis of this functionality.

Referring now to FIG. 3, there is described an example of application ofthe method for organizing and executing functionalities according to thepresent invention.

EXAMPLE

The functionality analyzed is the command for air conditioning of thepassenger compartment of a motor vehicle. It is described by a set ofCUs such that:

-   a) within the context in which the engine is running, the client    demands air conditioning, the response to which is the turning on of    the air conditioning and the signaling of such turning on.-   b) within the context in which the engine is stationary and the    client demands air conditioning, nothing happens

In the first analysis, this command can be illustrated by two blocks c1and c2 corresponding to contexts C₁ and C₂ of the automatic controllerin which the engine driving the vehicle is respectively running orstationary.

Within context C₁ of the automatic controller, the first and secondstates (C₁, R₁) and (C₁, R₂) are identified. The state (C₁, R₁)corresponds to “air conditioning not demanded” and therefore to anabsence of reaction, illustrated by the qualifier “none” correspondingto R₁.

The state (C₁, R₂) corresponds to “air conditioning demanded” upondemand D₁. The reaction R₂ is that an LED on the instrument panel thenglows to confirm to the driver that the air-conditioning has beenactivated by activation of a refrigerant compressor and regulationthereof to achieve a predetermined temperature in the passengercompartment as set by the driver and, as the case may be, by a demandfor additional torque to the motor, to avoid torque jolts, etc.

Within this context C₁, when the driver demands that theair-conditioning be turned off (demand D₂), this demand commands atransition of the automatic controller from the state (C₁, R₂) to thestate (C₁, R₁).

Within the context C₂ (engine stationary), a demand D₁ to activate theair-conditioning must not have any effect, because of the fact that thedriver does not usually remain in his vehicle when it is stopped. Thereaction to demands D₁ and D₂ is then always R₁ (=none).

The broken arrows illustrate the changes of state that result fromchanges of context of the automatic controller caused by the “stopengine demand” or “start engine demand”, which clearly illustrate thecase of a parameter (engine condition) that affects the functionalitybut is not affected by the functionality.

According to an advantageous characteristic of the inventive method, itis possible to develop the “air-conditioning” functionality describedhereinabove even if this development was not envisioned during thedesign of this functionality.

Thus, the automatic controller can be modified in such a way as to givethe driver the possibility of activating the air-conditioning even ifthe vehicle is not occupied.

Such a possibility adds additional comfort to the vehicle, in the sensethat the air of the passenger compartment can be brought to an agreeabletemperature even before the driver gets into this passenger compartment,when it has become overheated because the vehicle has been left to standfor some time in the sun, for example.

Within this context C₃, “vehicle unoccupied”, of the automaticcontroller, a distinction is made between two states (C₃, R₁) and (C₃,R₃). The broken arrows illustrate the changes of state resulting fromchanges of context of the automatic controller (occupant exits thevehicle, vehicle occupied).

Upon a demand D₁ of the driver located outside his vehicle, input bymeans of a remote command that in traditional form also causes thevehicle doors to be unlocked, the electrical system of the vehicle canbe activated in order to start up the interior ventilation of thevehicle and to roll down the windows of the vehicle. The set of thesecommands comprises the reaction R₃ of the state (C₃, R₃).

It is understood that this supplementary capacity of activation of theair-conditioning of the unoccupied vehicle can be easily added to theautomatic controller by input or remote input, into the RAM containingthe “tables of values” corresponding to the “air-conditioning”functionality, of a few supplementary numerical identifiers, whichcorrespond to C₃ and R₃ and therefore to a low data rate.

It is now apparent that the invention readily makes it possible toachieve one of the stated objects, that of providing, for organizationand execution of functionalities, a method designed to permitmodifications to the functionalities or addition of new functionalities,by means of simple additions to the initial programming.

By virtue of the use of an automatic controller that executes the“intermediate” language described hereinabove, the architecture of themicroprocessor hosting the automatic controller does not have to betaken into account when these modifications or new functionalities areintroduced. Such introduction is achieved by means of remote input of alight volume of supplementary instructions at low rate, and not bycomplete re-input of modified or added functionalities, such as knownfrom the prior art, constituting re-input of a heavy volume at highrate.

Of course, the invention is not limited to the “air-conditioning”application described hereinabove, and on to the contrary, extends toany other application that may have to be implemented in the environmentof a motor vehicle, such as, for example: control of opening/closing ofthe doors, activation/deactivation of an alarm, storage of adjustmentsspecific to the driver (seat, rear-view mirrors, etc.), connection of anavigation system to a motor-traffic information system or to any otherservice accessible via the Internet, etc., etc . . . .

Nor is the invention limited to the evolution of an existingfunctionality, and as indicated hereinabove, it also extends to theaddition of a new functionality.

The invention also extends to applications that take demands other thanthose originating from the vehicle driver into account. Thus, forexample, once the vehicle reaches a certain age or a certain mileage,actions of calibration or adjustment of the engine justified by its ageor wear condition could be triggered automatically.

The invention also extends to organizing and executing functionalitiesin an environment other than the motor-vehicle environment.

1. A method for executing a plurality of functionalities, comprising: a)defining a plurality of cases of use for each of which, within acontext, a demand invokes a reaction that implements one of saidfunctionalities; b) selectively activating the reaction upon detectionof transmission of the demand within the context; c) defining, for eachfunctionality implemented by a system of hardware and softwarecomponents, a plurality of cases of use of the functionality, each caseof use being composed of: a context corresponding to conditions ofapplication of the case of use, in a form of computerized parameters orof physical states of hardware components, a user's demand, and aresponse of the system to the demand, and wherein the system carries outthe response upon detection of the transmission of the demand within thecontext; d) for each functionality, automating execution of thefunctionality with an automatic controller of the system of hardware andsoftware components, transitions of the automatic controllerrepresenting demands of the cases of use and states representingexecution of responses of the cases of use, and e) identifying thecontext of the automatic controller that each represent a set of valuesof vehicle parameters that are not affected by the functionality butthat affect the functionality.
 2. A method according to claim 1, furthercomprising: during a designing, for each functionality: defining thestates corresponding to execution of the responses of cases of usewithin their respective contexts, and, in an iterative manner, until aniteration does not add a transition, for each case of use: identifyingpairs compatible with the context of the case of use, creating, in theautomatic controller, for each of the pairs, a transition that leads toanother pair by the demand of the case of use, the another pairincluding a state implementing the response of the case of use, and ifthe state does not already exist, adding the state within the context.3. A method according to claim 1, wherein the designing comprises:adding a formalized case of use of the functionality, specified by aninitial context or situation of the system, a user's demand to thesystem, and a response of the system corresponding to a change of itsstate, and, in an iterative manner for each already constructed state,performing a search to determine whether each already constructed stateis compatible with the context of the added case of use and, if so,constructing a new system state linked to the state already constructedby the demand for the added case of use, the new state taking intoaccount the already constructed state and its modification by theresponse of the added case of use.
 4. A method according to claim 1,wherein the context represents at least one mode of operation of thesystem, modes being available in all functionalities.
 5. A methodaccording to claim 4, wherein the modes of operation include at leastone of a mode representing an available energy level, a moderepresenting a type of user of the system, and a mode representing anaccident or non-accident condition of a vehicle.
 6. A method accordingto claim 5, wherein the context represents a context of the automaticcontroller of the system, composed of a complete combination of modes ofoperation of the vehicle, the context of the automatic controllerthereby being available to all functionalities, the cases of userepresenting all responses or absences of response of the system withinall context of the automatic controller, those representing together allcombinations of the modes of operation of the vehicle.
 7. A methodaccording to claim 1, further comprising a completing, wherein there areenvisioned, for each response, all the client demands not yet processedand a designer is asked whether processing of the demand must beperformed in the state corresponding to that response.
 8. A methodaccording to claim 1, further comprising a correcting wherein, for agiven state, if two states of the automatic controller are linkedthereto at the output by the same demand, a determination is madewhether it is necessary to eliminate one of the two states.
 9. A methodaccording to claim 1, further comprising a junction wherein, if twostates have a same interface with respect to other states, the twostates are combined in a single state.
 10. A method according to claim1, wherein said user's demand is implicit.
 11. A method according toclaim 1, wherein said functionalities are functionalities of a motorvehicle that includes said system of hardware and software components,wherein said context includes information related to said motor vehicleand detected by sensors on said motor vehicle, and wherein said user isa driver of said motor vehicle.
 12. A method according to claim 11,further comprising recording said context identified in said step ofidentifying.
 13. A method according to claim 4, wherein the modes areunaffected by the functionalities.